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[X] It is also accompanied by a copy of each prior art document cited in this report. 



1 . Basis of the report 

a. With regard to the language, the international search was carried out on the basis of the international application In the 
language in which It was filed, unless otherwise indicated under this Item. 

I I the International search was carried out on the basis of a translation of the international application furnished to this 
Authority (Rule 23.1(b)). 

b. With regard to any nucleotide and/or amino acid sequence disclosed In the international application, the International search 
was carried out on the basis of the sequence listing : 

I I contained in the International application In written form. 

I I filed together with the international application in computer readable form. 

I I furnished subsequently to this Authority In written form. 

I I furnished subsequently to this Authority in computer readble form. 

I I the statement that the subsequently furnished written sequence listing does not go beyond the disclosure In the 

international application as filed has been furnished. 
I I the statement that the Information recorded In computer readable form is Identical to the written sequence listing has been 

furnished 

2. Certain claims were found unsearchable (See Box I). 

3. Unity of invention is lacking (see Box II). 

4. With regard to the title, 

I I the text is approved as submitted by the applicant. 

pr| the text has been established by this Authority to read as follows: 

METHOD AND APPARATUS FOR STRUCTURED COMMUNICATION 



5. With regard to the abstract, 

pC] the text is approved as submitted by the applicant. 

□ the text has been established, according to Rule 38.2(b), by this Authority as it appears in Box III. The applicant may, 
within one month from the date of mailing of this International search report, submit comments to this Authority. 

6. The figure of the drawings to be published with the abstract is Figure No. 

I I as suggested by the applicant. 
I I because the applicant failed to suggest a figure. 
I I because this figure better characterizes the invention. 



None of the figures. 
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page 4, line 41 - page 5, line 21 




Y 




2-6,8,9, 






11-17, 
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page 6, 11 ne 6 - line 53 






page 7, line 41 - page 9, line 7 






page 12, line 1 - page 17, line 18 
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"O" document referring to an oral disclosure, use, exhibition or 
other means 

"P" document published prior to the international filing date but 
later than the priority date claimed 



later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle or theory underiying the 
invention 



"X" 



document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document is taken alone 

'Y" document of particular relevance; the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 
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2. This REPORT consists of a total of 4 sheets, Including this cover sheet. 

El This report Is also accompanied by ANNEXES, I.e. sheets of the deecrlptton. claims and/or drawings which have 
been amended and are the basts for this report and/or sheets containing rectifications made baforo this Authority 
(see Rule 70.16 and Section 607 of the Administrative Instructions under the PCT). 

Those annexes consist of a total of 13 sheets. 
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INTERNATIONAL PRELIMINARY 
EXAMINATION REPORT 



International application No. PCT/NL98/00586 



I. Basis of the report 

1 . This report has been drawn on the basis of {subsUtuts shMts whM% have been lumished to the recehmg Office in 
response to an invitation under Artide 14 are referred to m this report as 'orfghaJiy fiiedT and are not annexed to 
the report since tiiey do not contain amendments.): 



Description, pages: 

2.3,5-9,14-28, 

4.11-13,29 
1,10 



as originally filed 

as received on 
as received on 



29/1 Q/1 999 wtth letter of 
07/1 2/1 999 With letter of 



29/10/1999 
07/12/1999 



Claims, No.; 

1-28 



as received on 



07/1 2/1 999 with letter of 



07/12/1999 



Drawings, sheets: 

1/3-3^ as originally filed 

2- The amendments have resulted In the cancellation of: 

□ the description, pages: 

□ the claims, Nos.: 

□ the drawings, sheets: 



3. □ This report has been established as if (some of) the amendments had not been made, since they have been 
considered to go beyond the disclosure as filed (Rule 70.2(c)): 



4. Additional observations, if necessary: 



Forrn PCT/lPEA/40d (Boxes I-VIH, Sheet 1 } (January 1994) 
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V. Reasoned statement under Article 35(2) with regard to noveltyi inventive step or Industrial 
applicability; citations and explanations supporting such statement 

1, Statement 



Novelty (N) 


Yes: 


Claims 


1-28 




No: 


Claims 




Inventive step (IS) 


Yes: 


Claims 


1 28 




No: 


Claims 




Industrial applicability (lA) 


Yes: 


Claims 


1-28 




No: 


Claims 





2. Citations and explanations 
eee eeparate sheet 
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INTERNATIONAL PRELIMINARY International application No. PCT/NL98/00586 

EXAMINATION REPORT - SEPARATE SHEET 



Re Item V 

Reasoned staAement under Article 35 (2) with regard to novelty, inventive step or 
industrial applicability; citations and explanations supporting such statement 

The invention Is in the field of point-to-point communication between different data- 
bases by exchanging messages according to independent method claim 1 and 
independent apparatus claim 10, and system claim 27 making reference to the 
apparatus claims. 

Closest prior art to this application is document D1 (EP-A*0 456 249) disclosing a 
communication method in which messalges are transformed into a common format (the 
intermediate data representation) before being transmitted to another database system. 
The common message format has inherent restrictions. 

The invention is based on the problem to provide a communication method and 
apparatus for exchanging messages between different database systems wherein the 
messages may include whole application level programs. 

The invention overcomes this problem with a method and an apparatus for exchanging 
messages having a structured format including data fields and object fields. The 
method and apparatus further include databases at the respective end points of the 
communicating systems which allow the local inteip relation and processing of incoming 
messages. 

The prior art does not provide a hint in this regard. Therefore, the subject-matter of 
claims 1 and 10 is considered to be novel (Article 33 (2) PCT) and to involve an 
inventive step (Article 33 (3) PCT). Consequently, the subject-matter of the dependent 
claims 2 to 9 and 11 to 28 concerning embodiments of the method and the apparatus, 
respectively, is also considered to be novel and to involve an inventive step. 

There Is no doubt about the industrial applicability (Article 33 (4) PCT) of the subject- 
matter of all claims. 
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WO 99/20025 

^ FCT/NL98/00586 

^ aaims 

1. MeOiod of point-to-point communication between a sender (SRV(m)) and a 
receivra: (SRV(m)) by means of messages with flexible message formats (E.MF) char- 
acterirod in that any of said messages comprises: 

a header at least comprising message definition references (MSG ID, MSG 
CLASS, MSG VERSION, MSG CREATOR), a sender identifier (SENDER 
n>) and a destination address (DESTINATION ADDRESS); 
message content regazdiag: 

* number of fields (FIELD COUNT) and content of any field (FffiLD(l), 
-.-): 

* number of objects (OBJECT COUJO") and content of any object 
(OBJECT(l). ...); 

* number of field mappings (MAP COUNT) and content of any field map- 
ping (MAP(l), ...), any field mapping being usable by predetemiined fields; 

* number of axjtions (ACTION COUNT) and content of any actions 
(ACTION(l). ,.,), any action being at least usable by predetermined fields. 

2. Method according to claim 1. wherein said message definition references com- 
prise a message identifier (MSG ID) for identifying any of the messages. 

3. Method according to claim I or 2. whraein said message definition references 
comprise a message class identifier (MSG CLASS) for identifying a message class for 
any of the messages, like mail, business message, orders or shipping. 

4. Method according to any of the precedmg claims, wherein said message defini- 
tion references comprise a message version identifier (MSG VERSION) for identifying 
a version number of any of flie messages. 

5. Method according to any of the preceding claims, wherein said message defini- 
tion references comprise a message creator identifier (MSG CREATOR) for identifying 
a creator of any of the messages. 
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6. Method according to any of the preceding claims, wherein said header com- 
prises a reference to a type of encryption (ENCRYPTION TYPE) appUed. 

7. Method according to any of the preceding claims, wherein said header com- 
prises a reference to a type of compression (COMPRESSION TYPE) applied. 

8. Method according to any of the preceding claims, wherein said header com- 
prises a reference to an appUcation (APPLICATION NAME) for indicating whether or 
not any of the messages is member of a series of messages forming together said 
application, 

9. Method according to any of the preceding claims, wherein any of said mes- 
sages comprises a digital signature. 

10. A communication apparatus comprising processing means (ELMS) and a data- 
base (ILMDB), arranged for point-to-point communication with another communica- 
tion apparatus (SRV(m)) by means of messages with flerible message formats (ILMF), 
said messages comprising: 

a header at least comprising message definition references (MSG ID, MSG 
CLASS. MSG VERSION, MSG CREATOR), a sender identifier (SENDER 
ID) and a destination address (DESTINATION ADDRESS); 
message content regarding: 

* number of fields (FIELD COUNT) and content of any field (FlELD(l). 

* ntmiber of objects (OBJECT COUNT) and content of any object 
(OBJECT(l), ...); ^ 

number of field m^pings (MAP COUNT) and content of any field map- 
ping (MAP(l). ...), any field mapping being usable by predetermined fields- 
number of actions (ACTION COUNT) and content of any actions' 
(ACTIONd), -..). any action being at least usable by predetermined fields; 
sa,d proeessmg means aLMS) being ar^ged for consulting a predete^xined message 
definmon table (msgdef) stored in said database aLMDB) using said message defini- 
tion references as references to said predetemuned message definition table 
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11- A communication apparatus according to claim 10, wherein said predetennined 
message definition table (msgdef) comprises a message identifier (msgid) for identify- 
ing any of the messages. 

12. A communication apparatus according to claim 10 or 11, wherein said ptede- 
teraiined message definition table (msgdef) comprises a message class identifier 
(msgclass) for identifying a message class for any of the messages, like mail, bu^ess 
message, orders or shipping. 

13. A communication ^paratos according to any of the claims 10 through 12, 
wherein said predetermined message definition table (msgdef) comprises a message 
version identifier (msgver) for identifying a version number of any of the messages. 

14. A communication ^paratus according to any of the claims 10 through 13, 
wherein said predetennined message definition table (msgdef) comprises a message 
creator identifier (creatid) for identifying a creator of any of the messages. 

15. A communication qiparatus according to any of the claims 10 through 14, 
wherein said predetennined message definition table (msgdef) comprises a reference to 
a type of encryption (eacrtype) applied, 

16. A communication apparatus according to any of the claims 10 through 15, 
wherein said predetermined message definition table (msgdef) comprises a reference to 
a digital signature type (sigtype) q^plied. 

17. A communication apparatus according to any of the claims 10 through 16, 
wherein said predetemiined message definition table (msgdef) comprises a messagi 
system identifier (msysid) for use as a reference to fiuther tables in said database 
(ILMDB). 

18. A communication apparatus according to claim 17, wherein said ftirther tables 
comprise a field definition table (flddef) for holding primary definitions for any field 
of said messages. 
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19* A communication ^aratus according to any of the claims 17 or 18, wherein 
said further tables comprise a field mapping table (fldmap) comprising mapping infor- 
mation usable by predetermined fields, e.g. for mappings to hyper text markup lan- 
guage fields, database fields, flat file fields and other message fields, said database 
fields and flat file fields being stored in a customer database (CDB). 

20. A communication apparatus according to any of the claims 17 through 19, 
wherein said further tables comprise a field action table (fldact) comprising action 
information usable by predetermined fields. 

21. A communication apparatus according to any of the claims 17 through 20> 
wherein said further tables comprise a message pre-processing table (msgpre) com- 
prising a list of actions to be executed as pre-processing for a message either received 
or to be sent and a message post-processing table (msgpost) comprising a list of 
actions to be executed as post-processing for a message received. 

22. A communication apparatus according to any of the claims 20 or 21, wherein 
said field action table (fldact), said message pre-processing table (msgpre) and ssud 
message post-processing table (msgpost) comprise references to types of action 
selected from the following group of actions: database type of actions and logical type 
of actioxis including mathematical calculations, assignments, logical operations, condi- 
tional operations, and commands. 

23. A communication ^aratus accordmg to any of the claims 10 through 22, 
wherein said message definition table (msgdef) comprises an appUcation field 
(appmain) for indicating whether a message received is a first message of an appUca- 
tion and an application name field (appname) for referring to a name of said appli- 
cation. 

24. A communication apparams according to claim 23, wherein said application is 
a distributed application distributed over a plurality of communication apparatuses. 



communication apparatus according to any of the claims 10 through 24, 
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wherein said s^paratus is arranged for requesting a new message definition firom a 
sender if a message received refers to a message definition not present in its database 
(ILMDB), and receiving said new message definition &om said smder and storing it in 
said mess^e definition table (msgdef) in said database (ILMDB). 

26. A commmiication apparatus according to any of tiie claims 10 tiirough 25, 
wherin said processing means (ILMS) are arranged to either merge a message received 
with a designated HTML file or if the designated HTML file is not found by the pro- 
cessing means (ILMS)^ to create a default dynamic HTML file. 

27. A system comprising a conomiimcation apparatus (SRV(m)) according to any 
of the claims 10 through 25 and a torminal (ILMC) connected to said communication 
apparatus, said terminal comprising a terminal processor (1)> a display unit (6) and 
input means (12, 13) for inputting data by a user, said communication apparatus being 
arranged for passing a message received to said terminal if said terminal is indicated in 
the message to be the destination address, and said terminal processor (1) is arranged 
to either merge the message with a designated HTML file or if the designated HTML 
file is not foimd by the terminal processor (1), to create a default dynamic HTML, 
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Title 

Method of object oriented point-to-point communication and communication 
apparatus for carrying out such a method 

5 

Field of the Invention 

The present invention is in the areas of electronic data communications, data- 
base organized, flexible format electronic data message management, client-server and 
distributed software applications. 
10 In particular, this invention uses a relational database to describe and manage 

the creation, communication, interpretation, display and real-time responses to flexible 
format electronic data messages and applications organized as collections of flexible 
format electronic data messages which may be optionally distributed across one or 
more computer systems on one or more electronic data networks. 

15 

Background of the Invention 

General purpose and business specific electronic data communication meets 
with four distinct problems, each of which has many sub-problems. We will be dis- 
cussing these issues with regard to business communication needs, although the follow- 
20 ing points can apply to almost any category of electronic data communications. The 
four problems are: 

1) The electronic data that is sent and received must be clearly recognized for 
what it is meant to be. Each company has a different way of representing even the 
most basic business information, an order form or bill of lading, for example. 
25 2) Once electronic data is received from another company and correctly recog- 

nized, it must be integrated into the receiving company's databases and business pro- 
cessing programs. Here again, each company has many differences in their database 
structures, which means the way they represent and store their electronic data on their 
computer systems. 

30 3) If the electronic data must be displayed to an end user and allow for end 

user interaction, here again, each company may be using different types of computer 
display terminals with various types of display software, various system requirements 
and business requirements. It is very often necessary to build very expensive electronic 
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data display programs with customized graphical user interfaces. 

4) There may exist the need to execute the processing of computerized busi- 
ness functions in a coordinated manner, distributed across more than one computer 
system, due to the need to use a combination of specialized system services and their 
5 associated data to accomplish specific business functions. This means that a computer- 
ized business system might need to exist in more than one location, operate differently 
in one or more locations, but function, in essence, as if it were one, single system. The 
solutions to this problem are usually classified as distributed applications or, more 
recently, distributed object management systems that are classified as "middleware". 

10 There are really two distinct primary issues associated with problem four. The 

first is the need or desire of a company to use the same business application on many 
different systems, avoiding the need to rewrite the business logic, user interface and 
network communication interface for each different system that it needs to run on. The 
second issue is the need to divide the functionality of a single application over more 

15 than one system across a communications network, and have it operate in a fully 
coordinated manner. 

There is no single system currently that can solve all of these four problems. 
Businesses waste millions of dollars each year, buying, building, rebuilding and main- 
taining electronic data communication and storage systems that inefficiently and in- 

20 completely solve various combinations of these four problems. 

Prior Art 

Problem 1 

25 To solve the first problem, a set of electronic data formats for particular types 

of information must be agreed upon by all communicating companies before the com- 
munication actually takes place. Furthermore, the agreement upon the formats must be 
actualized by the use of communication software that uses these same exact agreed 
upon formats. EDI (Electronic Data Interchange) has been one approach to solving this 

30 problem. EDI is a set of electronic data message formats for many types of business 
transactions. The formats are not flexible, meaning they cannot be changed by the 
users, and there are quite a few different versions of EDI messages. A company could 
■ implement an EDI message business communication system and still not be able to 
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exchange electronic data with other companies using a different version EDI message 
set. The amount of time and money it takes to convert an existing business system to 
EDI is enormous and it is then difficult and expensive to change to, or add another 
format if that becomes necessary. 
5 Methods and solutions using hard-coded (i.e. defined in the software) message 

formats have all of the problems associated with EDI and in essence are the same 
solution, only with a different fixed message format. Every time that a fixed message 
format must be changed, this requires a similar change in the software as well as poss- 
ibly the database and user interface. Even a very small change can sometimes take 

10 months. And, of course, this electronic message format must be changed on the com- 
puters of every business using that particular format to insure that future electronic 
communication will continue correctly. 

Essentially there will always be the requirement that, in some way, a common 
data format must be agreed upon by the sender and receiver. This will be present in 

15 any method available, now or in the future. The critical issues for the customer are: 
how fast and cheap it is to build a system around a method (i.e.: EDI) and how easy it 
is to change a previously agreed upon electronic data format, in every part of the sys- 
tem (database, software, user interface). 

20 Problem 2 

The second problem is one that is harder to solve. In general, most companies 
use large numbers of data entry personnel, who are reading printed material and enter- 
ing the data that they have read into a computer program running on their terminal that 
will process this data, convert it to the correct format and place it in the company 

25 database. Those companies using EDI or a similar conmion electronic message format 
will quite often have paid a very large amount of money for customized software that 
processes and converts the common electronic message format automatically for them 
and interacts with their existing database structure for the purpose of data storage and 
retrieval. If they need to change or add to the common message format, or they need 

30 to change or expand their database structure then they must spend time and much 
money to have this electronic message format database interface program changed and 
re-written again. 

One newer public domain general purpose solution centers around "mapping" 
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specific data items to specific locations in a customer database or storage device. This 
mapping is not created in software, but is in some more easily changeable and flexible 
representation that is separate from the software application and customer database, 
such as an independent flat file that the software application reads. This eliminates the 
5 need to reprogram and rebuild the software application every time the database struc- 
ture or the data representation changes. Data field mapping techniques are in common 
use by many database companies such as Progress, Oracle and SQLBase (SQL = 
Structured Query Language). A version of this well know method may be part of the 
functionality and methodology incorporated into communication apparatus of the pres- 
10 ent invention. 

Problem 3 

The third problem has had few easily workable general purpose solutions. One 
category of solutions requires writing extensive amounts of software code for various 

15 window (graphical user interface) management systems such as X- Windows or Micro- 
soft Windows. For large, multi-functional business applications, this approach requires 
a tremendous amount of time, money and effort, and makes changes or additions to the 
user interface a very time consuming and costly affair as well. 

A new and promising category of solutions centers around the use of HTML 

20 (Hyper Text Markup Language) and web browsers, which can dynamically create very 
nice looking graphical user interfaces, usually called 'web pages', because they are 
used on the World Wide Web and the internet. This has aroused the interest of many 
companies. They see how quickly and cheaply very nice looking graphical user inter- 
faces can be built using HTML and they wonder if the user interfaces for their elec- 

25 tronic data communication and processing programs could be created in the same way 
and communicate over the same networks as the web browser systems. In fact, com- 
panies would like to be able to use the internet to send and receive the full range of 
business and personal data and messages. 

At the present time there are several systems available that will allow a limited 

30 range of business and general data communication over the internet, using HTML and 
web browsers. The reason that the types of data communication are limited is that the 
webserver/web browser systems were not designed to provide full data communication 
services. They were designed as dynamic document retrieval and display systems. They 
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can retrieve information that is first initiated as a request from the user. They do not 
give the user the capabiHty to send information to one or more destinations, except by 
extensive additional programming. The capabiUty for sending is not inherent in the 
system. Examples of this type are Progress* WebSpeed, IBM*s WebEDI and 
SapphireGroup's PageBlazer. 

Even the "newer" features of v^eb browsers and webservers that implement the 
so-called "push" technology only allow the receipt of data, not the sending. And this 
"receipt" is actually set up as a simulated broadcast receiver, a hidden repeating 
request for information (polling), by the web browser and webserver systems. The 
plans to expand this "push" technology only include the use of true broadcast and 
multi-cast communications technology. Examples of "push" technology are Marimba's 
Castanet and Tibco's TIB API. This so-called "push" technology is of great interest to 
advertisers that wish to reach a mass market in a new way, but is of almost no use to 
the company or individual wishing or needing to use the advanced document display 
features of HTML and the Internet in the context of fully integrated two way com- 
munication of information using point-to-point protocols that can be easily integrated 
into their existing database and business systems. 

The webserver and web browser interfaces for the Internet are set up to allow 
end users to send messages as requests for web pages. At no time will a web browser 
user be able to send a message to another web browser user, or send a web page to 
another web browser user, except through electronic mail. At no time will a web 
browser user ever receive a specific message that was not first asked for; even the so- 
called "push" technology information is requested by polling and the nature of the 
information, even when it is customized can be compared to a television broadcast or a 
mass mailing. The information is not being sent to one specific recipient. Contrast this 
with electronic mail (email), for instance. Using email services one can receive any 
number of specific, private, messages without asking the sender for them first. One can 
send any number of specific, private messages to particular recipients, without first 
being asked. This is the ordinary and necessary nature of messages. Yet the webserver 
systems of the internet were not designed to communicate like this. 

Why then are companies and people so interested in using them this way? Why 
don't they just use email? The answer is that email does not have any data formatting 
services built into it (as HTML does) and does not have any user interface generation 
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system built into it (as web browsers do). An email message may also take an indeter- 
minate amount of time (several seconds to several days) to reach its destination and 
sometimes can get lost. This is unacceptable for standard business electronic data com- 
munications. That is why companies and people like the webserver/web browser sys- 
5 tem, which has a very good data display capability built into it and moderately fast 
communications. However, as mentioned above it does not have point-to-point com- 
munication capability or data representation and mapping capability. 

In the present invention the public domain HTML standard may be incorpor- 
ated as the solution for generating very easily built, fast and flexible graphical user 
10 interfaces. 

Problem 4 

Historically, problem four has been addressed in a general way, until very 
recently, only by Relational Database Management Systems (RDBMS). This class of 

15 solutions has been and is restricted to solving the proper functionality of distributed 
query and distributed database management and does not address the primary two 
issues of problem four as described earlier. 

A second and newer class of solutions are to be found in systems currently 
referred to as "middleware" or distributed object management systems. A good 

20 example of this is a system called CORBA (Common Object Request Broker Architec- 
ture). An excellent set of articles on the development history of CORBA, the goals, 
current functionality and deficiencies of CORBA 2.0 can be found in Warren Kayffill, 
"CORBA masterminds object management" , p. 42, DBMS magazine, volume 10, 
number 3, March 1997, and T.J. Hart "Questioning CORBA. Bringing Corba-based 

25 designs to life faces a multitude of obstacles", p. 52 in the same issue of DBMS. 

This class of solution does not address the database interoperability issues, the 
common data format issues at the application level or user interface issues. It addresses 
solely the ability to write an application with standard communication interfaces and 
standard data at the communication level. Essentially this type of system supplies a 

30 development environment, a run-time environment and set of software libraries that 
allow programmers to create applications that will run on any system and, after defin- 
ing data structures in the code (so-called objects), these data structures can be 
exchanged with other software programs that have been coded to recognize and use 
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This capability and functionality is, in essence, not any different than a pro- 
grammer writing a message communication system in Java, which runs on almost any 
system, and using either EDI messages or some other agreed upon fixed format as a 
communication medium. The CORBA system does not interpret any messages. The 
application, written by the programmer, must be able to recognize the message. This 
leaves a CORBA application with all of the same issues for cost and time of develop- 
ment, alteration and maintenance as an EDI or fixed message format application sys- 
tem. Even the distributed functionality that is possible with CORBA is not inherent in 
CORBA, but in the skill of the programmer designing and coding the appUcation and 
use of the CORBA communication libraries. In essence, the only apparent gain of 
CORBA is the interoperability of 2^ of an application system across many run-time 
environments, which can perhaps be better gained through other means, such as Java. 

In essence, it appears that "middleware" in most cases is in fact just another 
electronic data communication environment that offers a standardized communication 
environment and some standardized software functionality on many computers, but 
fails to address all of the aspects of software application building and so requires the 
use of system dependent code for database interfaces and user interfaces, thereby 
defeating the main purpose for the use of a system such as CORBA. 

There are some systems that are merging CORBA functionality into Java and 
also including a standardized database interface called ODBC, or in the Java system 
JDBC. This is an interesting development, but as the ODBC database interface is only 
efficient for read-only queries, standard business transaction systems, which require 
full database access, can not be successfully created. Also, this combination does not 
address problems one or two at all. In addition, it is not the desired platform on which 
to build the present invention due to the use of ODBC and the unwieldy overhead of 
the CORBA object broker system. 

Further prior art is known from some patent documents which will be briefly 
discussed below. US 5,257,369 (Tibco, Inc) discloses "middleware" presented earlier. 
In addition, this document provides broadcast functionality and is based upon broadcast 
functionality. It is primarily to provide a solution to the problem of delivering real- 
time data to many recipients at once, such as in real-time stock quotes or market mfor- 
mation, and does not address point-to-point communications or problems 2 or 3 at all. 
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The message format is able to be changed and also defined as a data structure or 
object as described in CORBA earlier. However, this capability does not address the 
ability to change or add a message format without changing application code, or the 
ability to map the data of a message format to either a user interface or database fields. 

WO 96/20553 (Alphanet Telecom, Inc) focuses upon the enhancement of elec- 
tronic mail (email) services to include voice mail and facsimile (fax) information. The 
description of the system is of a centralized service which users can connect to for the 
receipt of voice mail, email or fax through the Internet, phone or fax machine connect- 
ing to the same service. This invention does not address in any way problems 1, 2, 3, 
or 4, but does address a way of possibly making email more efficient from a com- 
munications point of view. 

WO 96/34341 (Charles Bobo II) focuses upon a centralized service, that col- 
lects, stores and allows access to data for connected users. This is entirely different 
from the point-to-point communications necessary to solve problems I through 4 and 
for most types of standard business communications. In addition, there are many com- 
mercially available systems that have been in existence for many years that already 
function in exactly this way, such as GEIS and the IBM private data network, to name 
only two. 

EP-0,747,840 Al, EP-0,747,841 Al, EP.0,747,842 Al, EP-0,747,843 Al, 
EP-0,747,844 Al, and EP-0,747,845 Al (all of International Business Machines Cor- 
poration) are focused upon enhancing the current webserver functionality with some 
forms of database access and so are therefore still bound by the communications limi- 
tations of webservers discussed earlier. Therefore this set of inventions can not solve 
problems 1 and 4 at all and 2 and 3 in only a limited way. In addition, there are sev- 
eral commercially available systems that appear to offer the same or even more 
functionality in webserver enhancement such as WebSpeed ft-om Progress Database 
Corporation. 

WO 95/11560 (Sybase, Inc.) is in the category of "middleware" that solves 
only the problem of creating a consistent electronic data communications software 
interface which applications may be built upon, regardless of the computer hardware or 
operating system being used. This document does not address the format of the elec- 
tronic data being communicated in any maimer and so this solution is very similar to 
CORBA and has all of the same limitations from the point of view of the four prob- 
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lems being addressed by the present invention. 

EP 0 421 624 A2 (Texas Instruments Incorporated) is a combination of a 
"middleware" system such as CORBA, and an application development environment. 
Using a database controlled and administered software development environment, the 
claimed invention allows progranmiers to develop applications in C, COBOL and SQL. 
The database contains information which allows large groups of programmers to devel- 
op, modify and use source code control techniques for complex database transaction 
applications. The database also contains information that allows the application to be 
recompiled on alternate hardware systems and function in the same manner on each 
type of computer, although in this document mostly IBM mainframe systems and some 
Unix systems are discussed. The end result is a series of hard-coded, compiled applica- 
tions, with all of the same issues as described in problems 1 and 2 and only partially 
solving problems 3 and 4. 

EP-0,456,249 A2 (Hewlett-Packard Company) is a combination of a "middle- 
ware" system such as CORBA, and a partial application development environment 
whose primary capability is linking existing applications that have been developed in 
differing higher level programming languages. The higher level languages that are 
cited in this invention have different run-time in-memory organizations of their data 
and must transform the data from the organization of one language to another. To this 
end, an intermediate data representation and data transfer commands are defined that 
enable the invention, after compiling the data representation and transfer commands, to 
translate the identified data structures from the runtime representation of one language 
to another. This invention does not address in any way a message format that contains 
all of the data and commands necessary to run independently as an application, only 
the data and commands necessary to translate specified data structures between two 
pre-existing applications. Therefore, this invention does not address the issues dis- 
cussed in problems 2 and 3 at all and only partially addresses the issues in problems 1 
and 4 at the level of the programming language, not at the level of the appHcation as it 
has been discussed here. In contrast, in the current invention, the applications are com- 
posed entirely of the messages and therefore there is no translation of data from one 
language to another and no compilation of message formats or commands required; all 
of the data remains in the message format, whether it is being transmitted or it resides 
in the computer memory. 
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Given the above, an urgent need arises for a single system and a way of com- 
municating that can solve each of these four issues and combine the solutions into one 
unified whole. This would be of great benefit to the individuals and companies that 
must build complex electronic data communication systems and who must face these 
issues on a daily basis. Such a system and communication method would reduce the 
time, cost and complexity of building and maintaining electronic data communication 
systems drastically. 

To obtain the object referred to above, the present invention claims a method 
of point-to-point communication between a sender and a receiver by means of mess- 
ages with flexible message formats, characterized in that any of the messages com- 
prises: 

a header at least comprising message definition references, a sender identifier 
and a destination address; 
message content regarding: 

* number of fields and content of any field, 

* number of objects and content of any object, 

* number of field mappings and content of any field mapping, any field 
mapping being usable by predetermined fields; 

* number of actions and content of any actions, any action being at least 
usable by predetermined fields. 

Consequently, all of the elements for defining application level functionality 
are present in the message format, which is already in the context of a network com- 
munication system and therefore may be easily distributed by simply changing a loca- 
tion and destination address. 

Moreover, in accordance with the present invention, a communication appar- 
atus is claimed which comprises processing means and a database, arranged for point- 
to-point communication with another conrmiunication apparatus by means of messages 
with flexible message formats, the messages comprising: 

a header at least comprising message definition references, a sender identifier 

and a destination address; 

message content regarding: 

* number of fields and content of any field, 

* number of objects and content of any object, 



wo 99/20025 



PCT/NL98/00586 



11 

* number of field mappings and content of any field mapping, any field 
mapping being usable by predetemiined fields; 

* number of actions and content of any actions, any action being at least 
usable by predetermined fields; 

5 the processing means being arranged for consulting a predetermined message definition 
table stored in the database using the message definition references as references to the 
predetermined message definition table. 

Thus, in the present invention a flexible message format is defined that can 
contain any type of data and that contains enough information to fully describe the 

10 data within the message itself. Any message comprises message definition references 
which are used by the claimed communication apparatus receiving the message to 
identify a message definition preloaded in its database. However, the technology is 
flexible since the preloaded message definition is not fixed for once and for all. Within 
the communication apparatus receiving the message, message format specific instances 

15 can be created, edited or deleted by inserting, updating or deleting entries in relational 
database tables which fully describe the message and reference it with a unique ident- 
ifier. Moreover, if message definitions are absent at a desired location, entire database 
message definitions may be exchanged automatically for particular messages or groups 
of messages, thereby creating easily exchanged common format messages for multiple 

20 users. A further advantage of the present invention is the small amount of necessary 
overhead. 

Examples of fields within the message definition references are a message 
identifier for identifying any of the messages, a message class identifier for identifying 
a message class for any of the messages, like mail, business message, orders or ship- 
25 ping, a message version identifier for identifying a version number of any of the mess- 
ages, and a message creator identifier for identifying a creator of any of the messages. 
Any of these fields within the message definition references have equivalent counter- 
parts within the message definition table in the claimed communication apparatus. 

Moreover, headers of messages may include a reference to a type of encryption 
30 and/or compression used. Also these references, then, have counterparts in the message 
definition table in the communication apparatus. 

Preferably, the content of messages is protected by digital signatures. 

Preferably, the database of the communication apparatus is organized in several 
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tables to which reference is made from the message definition table. Then, the prede- 
termined message definition table comprises a message system identifier for use as a 
reference to further tables in the database. 

One of such further tables may be a field definition table for holding primary 
5 definitions for any field of the messages. 

Preferably, one of such further tables is a field mapping table comprising map- 
ping information usable by predetermined fields, e.g. for mappings to hyper text mark- 
up language fields, database fields, flat file fields and other message fields, said data- 
base fields and flat file fields being stored in a customer database. Then, the message 

10 format according to the invention contains not only data, but also mapping commands 
for user interfaces, customer database fields, and sequences of actions including calcu- 
lations and conditional logic. Consequently, all of the elements for defining apphcation 
level functionality are present in the message format, which is already in the context of 
a network commimication system and therefore may be easily distributed by simply 

15 changing a location and destination address. Moreover, in this way the HTML standard 
may be incorporated for generating very easily built, fast and flexible graphical user 
interfaces, allowing a direct mapping to and firom the message format defined by the 
invention, as managed, defined and controlled by the claimed communication apparatus 
and displayed and interacted with on a user terminal, like a microprocessor, connected 

20 to the communication apparatus. 

Additionally, one of such further tables may be a field action table comprising 
action information usable by predetermined fields. 

Preferably, further tables are a message pre-processing table comprising a list 
of actions to be executed as pre-processing for a message either received or to be sent 

25 and a message post-processing table comprising a list of actions to be executed as 
post-processing for a message received. 

The field action table, the message pre-processing table and the message post- 
processing table comprise references to types of action selected from the following 
group of actions: database type of actions and logical type of actions including math- 

30 ematical calculations, assignments, logical operations, conditional operations, and com- 
mands. 

Preferably, in the present invention, applications are defined as a named group 
of one or more messages. To that end, the message definition table comprises an appli- 
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cation field for indicating whether a message received is a first message of an appUca- 
tion and an application name field for referring to a name of the application. 

In accordance with the present invention, the claimed communication apparatus 
is, preferably, arranged for requesting a new message definition from a sender if a 
message received refers to a message definition not present in its database, and receiv- 
ing said new message definition fi-om said sender and storing it in said message defini- 
tion table in said database. 

The processing means of the communication apparatus may be arranged to 
either merge a message received with a designated HTML file or if the designated 
HTML file is not found by the processing means, to create a default dynamic HTML 
file. However, alternatively, the processing means of the communication apparatus may 
instruct a connected terminal to carry out these functions. Therefore, the present inven- 
tion also relates to a system comprising a communication apparatus as defined above 
and a terminal connected to the communication apparatus, the terminal comprising a 
terminal processor, a display unit and input means for inputting data by a user, the 
communication apparatus being arranged for passing a message received to the ter- 
minal if the terminal is indicated in the message to be the destination address, and the 
terminal processor is arranged to either merge the message with a designated HTML 
file or if the designated HTML file is not found by the terminal processor, to create a 
default dynamic HTML. 

Thus, user terminals that receive a message for which the terminal processor 
does not have the corresponding message definition can rely upon the system's auto- 
matic interpretation and display which is based upon the self-describing information 
contained within the message received. This same self-describing information can then 
be used by the terminal processor to automatically create a default database message 
definition if the database message definition referred to by the message can be found. 
Such a default database message definition can then be edited and adapted to the local 
system by the terminal user. 

The present invention may include a state of the art solution for problems two 
and three combined in a unique way with completely new solutions to problems one 
and four, all built around a unique flexible format electronic data message management 
system composed of the claimed flexible message format and communication appar- 
atus. 
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The message management system of the present invention, which is defined 
and controlled by detailed information stored in the tables of a relational database, 
allows for the most efficient, complete and simple to use way of communicating elec- 
tronic data in flexible formats. The flexible message format allows the inclusion of any 
5 form of electronic data. The flexible message format contains information that allows a 
receiver to interpret, understand and display the contents of the message, even if it has 
previously never been received. The receiver can also add this unknown message for- 
mat to its own message database and link it into its business databases and an HTML 
user interface very easily and quickly, without writing or changing any software. An 

10 HTML user interface can also be dynamically generated by the software of any ter- 
minal in the case where there is no specified, previously created HTML file. This 
addresses the first issue. 

In the present invention, an ANSI standard SQL interface to the major rela- 
tional databases may be provided. This interface provides the service of automatically 

15 linking the user selected fields of a data message to the fields in a relational database 
table, for subsequent storage or retrieval. This data mapping interface can also link to 
flat file formats such as fixed length fields and CSV (comma separated value) files. 
This data mapping interface can be expanded to link message data fields to many other 
formats, such as SNMP and manufacturing protocols for automatic process control, 

20 This data mapping interface is defined by entries in the ILMDB and controlled by the 
ILMS. This addresses the second issue. 

In the present invention, a message control user interface terminal may be 
provided, where a user may create, edit, receive, send and view messages. The mess- 
age control user interface communicates to a network and message management server 

25 arranged in accordance with the invention. In essence, the present invention replaces 
the current webserver/web browser technology for those individuals or companies that 
need full data communications capability, and expands the system domain to include 
any data communications network. This allows the full sending and receiving of 
HTML, VRML and Java appletes, as well as any specific data the user has defined to 

30 be in a particular message. When combined with the previously described features, this 
provides the full, database controlled linking between the data in a message, the cus- 
tomer data source it must be retrieved from or stored in, and the graphical user inter- 
face (HTML, etc.) it must be displayed with. 
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In addition to solving the issues described above, the present invention has 
added the capability of defining automatic, system perfomied actions, that may be 
organized as message pre and post processing, or, in the case of messages linked with 
a graphical user interface, field selection actions. These actions may be defined as SQL 
5 or as an "InterLingua'^'^ Script". "InterLingua™ Script" (IS) is defined in the present 
invention and is a simple, yet powerful set of calculation, execution and conditional 
logic control statements, that are dynamically interpreted and executed in real-time, 
and can interact with all message data fields. The actions can generate a new message, 
call built in system functions and external programs or send and receive database 

10 queries. These actions can be used to generate an automatic message response, auto- 
matic field validation, perform calculations, run a Java applete or a complex database 
transaction, for example. 

In the present invention we have included the truly unique method of an appli- 
cation being defined as a set of messages and their associated actions. Due to the rich- 

15 ness and flexibility of the interaction between the messages; their ability to run data- 
base transactions, merge with or generate graphical user interfaces, or run silently in 
the system as a background process, it is possible to fully define a complex application 
as a collection of data messages and their associated actions. This also has vast impU- 
cations in the realm of distributed application processing, as these messages are, by 

20 their very nature, sent, received, understood and organized with great ease, as a basic 
function of the system. This means that for the first time, a distributed application 
system could easily and flexibly define, without changing or adding any software code, 
the local user interface and customer data source interface (such as the business data- 
base) at each site and still be using the same application (message set). 

25 

Brief Description of the Drawings 

The invention will be explained with reference to some drawings which are 
only intended to illustrate and not to limit the scope of the invention. 

Figure 1 shows a general overview in block diagram of the system according 
30 to the invention; 

Figures 2a, 2b, 2c, 2d, and 2e show a message format according to the inven- 
tion. 
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Description of the Preferred Embodiment 

In figure 1 a plurality of servers SRV(m), m = 1, M, is shown. Any of the 
servers SRV(m) may be connected to one or more terminals. The terminals connected 
to server SRV(l) are referred to with ILMC(n), n = 1, N. The acronym "ILMC" 
5 has been derived from InterLingua™ Message Client. The connections are numbered 
with references 4, 5. 

Moreover, server SRV(l) is connected to a customer database CDB(l). 
Although one customer database CDB(l) is shovra, more than one can be applied as 
required. 

10 Terminal ILMC{1) has been depicted in greater detail in figure 1. Terminal 

ILMC (1) is shown to include a monitor screen 6, a processing unit 1, a keyboard 12, 
and a mouse 13. The keyboard 12 and the mouse 13 are connected to the processing 
unit 1. Of course, any other known means for inputting data to the processing unit 1 
by a user is possible instead of or in addition to the keyboard 12 and the mouse 13. 

15 The monitor screen 6 shows some "buttons" 7, 8, 9, 10, 11. These buttons can 

be acted upon by the user by means of the mouse 13 to instruct the processing unit 1 
to carry out predetermined tasks. Such predetermined tasks may be the opening of 
options, establishing connections, sending messages, receiving messages, and/or load- 
ing of data into the memory of the processing unit 1. 

20 The server SRV (1) is provided with a processor called InterLingua™ message 

server ILMS for receiving, passing or sending messages in accordance with the method 
of the present invention. Part of the ILMS processor is indicated with IS (= 
InterLingua™ Script), the function of which will be explained later. 

Server SRV (1) also comprises a database ILMDB (= InterLingua'^'^ Message 

25 Database) for storing several tables in accordance with the present invention, as will be 
explained later. 

The server SRV (1) is arranged for point-to-point communication with one 
other server through a communication path 2. The communication path 2 may be 
established in any known way, i.e., either by wires or wireless. 
30 Figure 1 shows several other servers SRV (m) connected to one or more ter- 

minals ILMC's. These further servers SRV (m) are organized in accordance with the 
present invention further explained in detail below. 

Figures 2a, 2b, 2c, 2d, and 2e show a message format. In figure 2a, the mess- 
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age format is shown to include four fields MSG Id, MSG Class, MSG Version and 
MSG Creator, used as message definition references by any apparatus receiving the 
message. 

The field MSG Id is to identify the message. 
5 The MSG Class is used to designate a category or type of message, like mail, 

business message, orders, or shipping. 

The field MSG VERSION comprises a message version identifier for identify- 
ing a version number of the message concerned. 

The fourth field MSG CREATOR comprises a message creator identifier for 
10 identifying a creator of the message concerned. 

The MSG Id, Class and Version fields are integer values. There are, e.g., 
1,000,000 MSG Ids per MSG Class and 10,000 MSG Classes. Every MSG Id, MSG 
Class pair can have, e.g., 100 MSG Versions. MSG Classes may e.g. be arranged as 
follows. MSG Classes 1 to 20 are reserved for the ILMS. MSG Classes 21 - 100 are 
15 pre-defined categories such as order placement, shipping, etc. The 9900 remaining 
MSG Classes are for user definition. The MSG Creator may e.g. have 80 characters. 
This is for the purpose of identifying entire message sets created by particular users or 
companies for easy automatic transfer. 

Together with five more fields these message definition references form a 
20 header to the message. These five more fields are: SENDER Id, DESTINATION 
ADDRESS, ENCRYPTION TYPE, COMPRESSION TYPE, AND APPLICATION 
NAME. 

The Sender Id is the user name as recognized by the server SRV(m) with the 
name of the server SRV(m) appended, e.g., in a manner similar to an email address 
25 (i.e. user-xyz@ilserver.com). The field DESTINATION ADDRESS is for identifying 
the address to which the message concerned is to be transmitted. The destination 
address may be of the same format as the SENDER Id. 

The field ENCRYPTION TYPE is used for a reference to a type of encryption 
applied, if one is required. The field COMPRESSION TYPE is to indicate the type of 
30 compression used, if required. 

The field APPLICATION NAME is used for indicating whether or not the 
message concerned is member of a series of messages which together form one appli- 
cation. 
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The Field Count gives the number of fields, e.g., from 0 to 256 in the mess- 
age. A "field" and its content refer to a particular type of data and the data itself. The 
actual field data follows this field, if the count is more than 0. With reference to figure 
2b, a field is defined by a Type identifier, a Size value, a field Name for internal 
identification, a field Label for default display, and a field Description, also for default 
display. The length of data following is know by combining the information of the 
Type and Size fields. One field definition follows directly after another with no addi- 
tional separators. 

Very often, particularly in HTML type data, there is a reference to a local file 
containing binary image, sound or program data. To insure the correct transfer and 
referencing of these referenced external objects, they are automatically grouped at the 
end of the message, as shown in figure 2a. The fields that reference them are made to 
point to the objects. When the message is received, these objects are automatically 
stored locally and the field references are automatically adjusted to access the objects 
in their new location. The Object Count field gives the number of objects in the mess- 
age from 0 to 256. The object data follows this field, if the count is more than 0. An 
Object is, preferably, defined by a MIME Type/Content identifier, a Size value and 
then the actual Object Data, as shown in figure 2c. One Object definition follows 
directly after another, with no additional separators. 

With reference to figure 2d, a field mapping is e.g. defined by a FIELD IDEN- 
TIFIER, a MAPPING TYPE, and MAPPING DATA. As Figure 2e shows, actions can 
be simply defined by ACTION TYPE followed by ACTION DATA. 

A digital signature, using a server SRV key, is, preferably, created on the 
entire message and added at the end of the Object list. 

The allowed data types as defined in figures 2a, 2b, 2c, 2d, and 2e are for 
instance: 

1) Unicode character strings; 

2) Computer hardware independent integers of any size; 

3) IEEE 8-byte format floating point numbers; 

4) Universal Resource Locators (URL); 

5) Image data in GIF or JPEG format; 

6) MIME specified data representations. 

In actuality, GIF and JPEG data are also included as MIME types. The deci- 
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sion to make a specific data type for images in these foraiats was driven by the fre- 
quency of their use in HTML types of display systems. The most commonly used data 
types have their own definition. Any additional data types can be included as existing 
MIME types or specific MIME extensions. These data types are specified by way of 
5 example only. The scope of protection of the present is not intended to be limited by 
the type of data preferred. 

Each message may have its own digital signature and optional encryption and/- 
or compression, which is managed automatically by the server SRV(m). 

10 Message Database 

A flexible message format definition, management and control system is imple- 
mented using database ILMDB as a relational database as a holder of 

a) detailed message definitions; 

b) message mapping instructions: 

15 b.l) mapping to customer database fields; 

b.2) mapping to customer flat file formats; 

b.3) mapping to customer user interface (HTML) fields; 

b. 4) mapping to other message fields; 

c) message action lists: 

20 (SQL, Java, calculations, logic flow, message calls, external program calls) 

c. l) message pre-processing actions; 
C.2) message post-processing actions; 

c.3) message field user interface event actions. 
This information is held in tables in the relational database ILMDB and allows 
25 the system to fully interpret and process any message. New message definitions may 
be added and old definitions may be changed. Message definitions may be sent from 
one server SRV(m) to another for immediate incorporation into the message database 
ILMDB. Every flexible message format includes enough self-description information in 
itself to allow a server SRV(m) to interpret a previously unseen message and create a 
30 new message definition entry in the ILMDB for it automatically. This new message 
definition may be edited and enhanced by a system administrator, to complete the 
mapping into the receiver's system. 

Message data is not kept in the database ILMDB, only the definition. The 
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message data is kept in compressed files on a disk storage system. These files are 
periodically either archived or deleted according to the server message duration options 
chosen by the system administrator. 

The primary relational tables within the database ILMDB needed to define and 
5 control a message either received or to be sent are as follows: 

Table Name Description 



10 msgdef InterLingua™ Message Definition 

flddef Message Field Definition 

fldmap Field Mapping 

fldact Field Action Definition (one action per field) 

msgpre Message Pre-processing (sequence of message 

15 actions) 

msgpost Message Post-processing (sequence of message 
actions) 



System developers skilled in the art will recognize that there are many other 
20 tables of related information necessary to make an entire system more easily usable, 
and control secondary system features. Examples of this might be all of the tables 
associated with user accounts and user information, system administration and system 
security. The tables presented here are the core tables necessary for implementing the 
present invention in accordance with the preferred embodiment, and extensions or 
25 enhancements are considered to be within the scope of the present invention as well. 

Table: msedef 

This table is responsible for holding the primary definition of a message. A 
message is completely identified by the first four fields of this table, which are also in 
30 the message header (cf figure 2a). The fifth field (msysid) is an identifier that is 
assigned internally by the server processor ILMS, and is used as a reference for identi- 
fication of and fast access to other tables within the database. 
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Field Name Type Description 



msgid integer Message Identifier 

5 msgver integer Message Version 

msgclass integer Message Class 

creatid char Creator Identifier 

msysid integer Message System Id 

creatdate date Date Created 

10 usedate date Date Used 

These two fields control how long a message is stored by the ILMS. 
durdays integer Duration Days 

durmins integer Duration Minutes 

These two fields identify the type of encryption and digital signature algorithm. 
15 encrtype char Encryption Type 

sigtype char Digital Signature Type 

This field indicates whether the message is for display or not, 
silent boolean Message Silent Flag 

This field indicates whether the message can initiate or respond to actions, 
20 active boolean Processing Enable Flag 

msgicon char Message Icon File (for ILMC display) 

msghtml char Message HTML File (for ILMC display) 

This field indicates whether the message is the first in an application, 
appmain boolean Application Main Flag 

25 This field contains a name if the message is part of an application, 

appname char Application Name 

descr char Message Description 



Table: flddef 

30 This table is responsible for holding the primary definition for all fields of all 

messages. A field is uniquely identified by the 'msysid' assigned in the 'msgdef 
table and either a field sequence number (fldseq) or a field name (fldname). 
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Field Name Type Description 

msysid integer Message System Id 

5 fldseq integer Field Sequence 

fldname char Field Name 

These three fields are used to create 1, 2 (tables), or 3 dimensional arrays. 
arl integer Array Dimension 1 

ar2 integer Array Dimension 2 

10 ar3 integer Array Dimension 3 

fldtype char Field Data Type 

The field size is interpreted differently, depending on the data type. 
fldsize integer Field Size 

This field is used if the field is a reference to another message as a data struc- 
1 5 ture, 

smsysid integer Sub-Message System Id 

These two fields are used if the field contains MIME data, 
mimecont char MIME Content Identifier 

mimetype char MIME Type Identifier 

20 fldlabel char Field Label (for ILMC display) 

fidcom char Field Comment (for ILMC display) 



Table: fldmap 

This table is responsible for holding any mapping information that a field 
25 might use. This table can define mappings to database fields, flat file fields and other 
message fields. The field is identified in the same manner as table 'flddef . There is 
one mapping for data and one mapping for display allowed for each field, except in 
the case where a field is defined as an array. A data and display mapping can be 
assigned to one or more elements or dimensional rows of an array. 



30 
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Field Name Type Description 

msysid integer Message System Id 

5 fldseq integer Field Sequence 

fldname char Field Name 

These three fields allow mappings to specific array elements or dimension 
rows. 

arl integer Array Dimension 1 

10 ar2 integer Array Dimension 2 

ar3 integer Array Dimension 3 

This field allows the data to be transferred from the most recently active previ- 
ous message within the same message context, which is the set of currently 
active messages for a particular user connection, 
15 cpyfld char Copy Field (From Msg) 

These three fields are used to specify a particular field in a SQL accessible 
relational database. 

dbnam char Database Name 

tblnam char Table Name 

20 fldnam char Field Name 

This field specifies a field in an HTML file (msgdefmsghtml) for display. 

tagnam char HTML Tag Name 

These two fields specify a fiat file of either fixed field lengths, or comma separ- 
ated values, 

25 flatfile char Flat File Name 

filetype char File Type (Fixed, CSV) 

These four fields specify the field location for the flat file, 
rowbegin integer Row Begin 

colbegin integer Column Begin {or Field # for CSV) 

30 rowend integer Row End 

colend integer Column End 



Table: fldact 

This table is responsible for holding any action information that a field might 
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use. Actions may be database type of actions and logical type of actions. There is one 
action per field, except in the case where a field is defined as an array. An action can 
be assigned to one or more elements or dimensional rows of an array. 

Field Name Type Description 



msysid integer Message System Id 

fldseq integer Field Sequence 

1 0 fldname char Field Name 

arl integer Array Dimension 1 

ar2 integer Array Dimension 2 

ar3 integer Array Dimension 3 

This field defines the action type: SQL or IS, file or local. 
15 acttype char Action Type 

This field contains SQL, IS or a file name whose contents are SQL or IS, 

actscript char Action Script 

Tables: msgpre and msgpost 

20 The two tables msgpre and msgpost have an identical structure. Table 

'msgpre' holds the list of actions to be executed by server processor ILMS as pre- 
processing for a particular message. This means before any display or field actions 
take place, the server processor ILMS completes the list or pre-process functions. 
Table 'msgpost' holds the list of actions to be executed by the server processor ILMS 

25 as post-processing for a particular message. This means that after all other message 
actions and displays have completed, the server processor ILMS completes the list of 
post-process functions before deleting the message from main memory. The process 
sequence number is used to create a controlled execution of the list of actions. A pre- 
vious sequence number must complete before the next one can begin. If there is more 

30 than one action with the same sequence number, they are started at the same time, or, 
within a multiple CPU or massively parallel environment, as true parallel processes. 
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Table: msgpre 
Field Name 



msysid integer Message System Id 

procseq integer Process Sequence 

This field defines the action type: SQL or IS, file or local. 
proctype char Pre-processType 

10 This field contains SQL, IS or a file name whose contents are SQL or IS, 

procscript char Pre-process Script 

Table: msgpost 

Field Name Type Description 
15 

msysid integer Message System Id 

procseq integer Processing Sequence 

This field defines the action type: SQLor IS, file or locaL 
20 proctype char Post-processType 

This field contains SQL, IS or a file name whose contents are SQL or IS, 
procscript char Post-process Script 

InterLingua"^^ Script (Action Defmition and Control Language") 

25 Any action, for either message pre-processing, post-processing or field actions 

can be either an SQL-action or IS-action. SQL (Structured Query Language) is an 
ANSI standard interface language for relational databases. IS (InterLingua™ Script) is 
a predetermined part of the server processor ILMS (cf. figure 1) and is a small, but 
powerful set of calculation, execution and conditional logic statements that give appli- 

30 cation level functionality to a message. In a preferred embodiment, the definition of IS 
is as follows: 
Calculation 

The operations of add (+), subtract (-), multiply (*) and divide (/) are allowed 
upon integers and floating point values. Parenthesis "( )" are allowed for grouping 
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mathematical operations. 
Assigmnent 

Assigmnent (=) is allowed to integers, floating point values, strings and URLs. 
Logical and Conditional 
5 Symbols representing: and (AND), or (OR), greater than (>), less than (<), 

greater than or equal to (>=), less than or equal to (<=), equality (=), not equal (!=), 
and negation (!) are allowed upon integers, floating point values, strings and URLs. 

Control Flow 

1 0 END-MSG - End a message. Must be last command from its own pre-processing list. 

END-APP - End an application. Must be last command from a member message post-processing 

list. 

15 For Loop: 

FOR i = X TO y 
BEGIN 

<statements> 
END 

20 

While Loop: 

WHILE <condition> 
BEGIN 

<statements> 
25 END 

If-Then-Else: 

IF <condition> THEN 
BEGIN 

30 <statements> 

END 

ELSE 

BEGIN 

<statements> 
35 END 
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Command 

Load mapped field data: 

LOAD {WHERE <extemal field naTne> = <value>} 

5 Store mapped field data: 

STORE {WHERE <extemal field name> = <value>} 

Execute external program: 

CALL [ JAVA [ EXEC | SHELL ] <program name> <paraTneter 1> ... <parameter n> 

10 

Execute message: 

ILMP://<host-TiaTT)e>/<message id> 

Execute internal fiinction (this is used mostly for user interface events): 
15 ILMP://<host-name>/<message id>/<field id> [ UI-ACT | MSG-END | APP-END ] 

ILMP://<host-name>/<Tnessage id>/<field id> [ ADD-DATA 1 DEL-DATA ] CHG-DATA ] <data> 

Applications 

A collection of InterLingua™ messages may be grouped together, uniquely 
20 named and used as an InterLingua™ application. For the purposes of this discussion, 
for any programming language or system platform, an application is defined as being 
one or more functions whose sequence of operation may vary depending upon input 
data and user and system events; that can access and interact with external storage 
devices; and that can interact with users through a user interface. 
25 All or part of this named set of messages may reside on one or more servers 

SRV(m) in one or more locations. This named set of messages, or application, imple- 
ments: 

a) a directed series of functions 

b) local and shared data 
30 c) user interface screens 

d) networked distributed application functionality 

The directed series of functions may include any of the action types, such as 
database queries, calculations and the activation of additional messages. Activating a 
message in this context can be used for the equivalent of calling an application func- 
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tion, displaying the next user interface screen, or, of course, sending a message to a 
local or external network destination. The real-time structured flow of the order of 
operations, or, in other words, the directed series of functions, is determined by the 
message action lists and also event actions generated by the user interface, such as a 
5 mouse selection of a field or a button. 

The local and shared data includes any of the allowed data types. These data 
types may be grouped into data structures. This message data may be mapped to and 
from user databases, user interfaces and passed to other messages. This concept makes 
use of a message as a function that may have its own local data and may call other 

10 functions (messages) to which it may pass any local data. When this local data is 
passed between two or more messages it becomes shared data. 

The networked distributed application functionality is implemented by using 
the inherent capabilities of the InterLingua™ clients ILMC(n) and servers as message 
senders and receivers. If an application set is created to run in a distributed manner 

15 across several servers as contrasted to a single application on one server, the primary 
difference will be that one or more of the messages acting as an application function 
will have a remote server as its destination, rather than the local server. This makes the 
creation of networked distributed applications very straightforward, with a simplicity 
and flexibility that has not been seen before. 

20 

InterLingua™ Message Client TILMC) and Server SRV 

The software of the InterLingua™ Message Client (ILMC) is, preferably, writ- 
ten entirely in Java, thus ensuring that it can run on any Java enabled computer sys- 
tem, which includes almost all of the most commonly used computers. The ILMC 
25 functions as an HTMLA^RML/Java Applete display console and as a network com- 
munication interface to the server SRV(m). 

The user interface screens make use of the ability to associate a message with 
an HTML definition and map the data between the message and the HTML display. 
This allows the chosen functions (messages) to have a user interface as necessary. User 
30 keyboard and mouse events are linked to field actions. 

The communication sub-system, implementing the message send/receive func- 
tions from one server to an other server and between a server and a terminal ILMC, is 
designed to work in a highly optimized, multi-threaded fashion, and replaces the use of 
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checksums for monitoring message integrity with the use of digital signatures. This 
allows for complete confirmation of the non-corrupted state of the received message 
and, at the same time, the security verification of the identity and authenticity of the 
sender. The communication sub-system exists in both the server SRV and the terminal 
ILMC. The communication sub-system is designed to be network protocol indepen- 
dent. In its current version it will run on TCP/IP, XTP/IP and XTP/ATM/AAL5, but it 
will just as easily run on AppleTalk, IPX, SNA, X.25, DECNET, OSI or any other 
protocol that can use a socket interface and point-to-point addressing scheme. 

The communication sub-system is not a critical part of the present invention. 
The advances of the present invention may be implemented over many different types 
of communication sub-systems. Those skilled in the art will recognize that the type and 
implementation details of the chosen network communications sub-system will not 
change the functionality of the present invention, as long as the communication sub- 
system has a reliable delivery protocol that can guarantee a high rate of delivery suc- 
cess and data integrity. 

A message priority scheduling and service mechanism as described and 
claimed in European Patent Application 97202945.8 may be added to the communica- 
tion sub-system. This mechanism uses separate connections for individual priority 
levels and a simple network and system buffering algorithm to automatically guarantee 
fair service for all message priority levels. This mechanism delivers high priority mess- 
ages faster consistently, without the need for a complex scheduling algorithm to moni- 
tor message sizes or prevent lower priority message lock-out. 

Receiving A Message 

When a message is received by a server SRV(m), it will pass through the 
communication sub-system. The digital signature will be verified and the transport 
layer header will be stripped. If the message has been encrypted or compressed it will 
be decrypted or decompressed at this time. The message will then be passed to the 
database layer ILMDB. 

If message definitions are absent at a desired location, entire database message 
definitions may be exchanged automatically for particular messages or groups of mess- 
ages, thereby creating easily exchanged common format messages for multiple users. 

Alternatively, if a message definition does not exist for the message received it 
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will be sent to the in-box of the system administrator. The system administrator can 
then examine the message using a terminal ILMC, automatically add the basic message 
definition and link the message fields to local database fields and HTML display fields 
as necessary. The system administrator may also automatically request that the sender 
of the message send the complete message definition which will then automatically be 
placed in the local database ILMDB. This request is sent out as a message from one 
server to another server. 

If a message definition exists for the message received, it will be read from the 
database ILMDB. The message pre-processing action lists will be executed by the 
server SRV(m), enacting functions such as message field validation, database queries, 
calculations and other messages. If the message is sent to a user for display, the pro- 
cessor 1 of terminal ILMC will either merge the message with the designated HTML 
file or if the designated HTML file is not found by processor 1, it will create a default 
dynamic HTML. The field actions may be activated by specific mouse and keyboard 
events if they have been defined in the message. Field actions may call a standard 
HTTP URL, send a request for the display of local image, activate a SQL database 
transaction, update local display data or run an InterLingua™ Script (IS) command. If 
the message has no user interface defined it is referred to as "silent", and its presence 
in the system can only be seen by the system administrator. 

At the completion of the silent message pre-processing and encountering an 
END-MSG command or the terminal message user interface sends an END-MSG 
command, the message post-processing action lists will be executed by the server 
SRV(m). If the message is part of an application set, it will remain active and in mem- 
ory until the server SRV(m) encounters or receives an END-APP. When an application 
set completes, all member message post-processing lists will be executed by the server 
SRV(m) if they have not yet been executed. This functionality also guarantees the 
automatic maintenance of transaction context and application data and state. When a 
single message or application set completes, the system memory will be cleaned and 
returned for use by other messages and applications. 



Sending a Message 

From a terminal ILMC: 
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A message format (ILMF) has been requested and received from the ILMDB/- 
ILMS. The message content and address has been added by the terminal user. The 
terminal user initiates a message send, through a user interface action, to the server on 
which the user is registered. 

From a server SRV(m): 

A message may be initiated automatically as the result of a direct call to acti- 
vate a message on the server SRV(m) through InterLingua"^^ Script (IS), or may be the 
request of a connected terminal which is first received and processed by the server 
SRV(m). The server performs the message pre-processing if any is defined. If the 
destination address is for the server itself, the message post processing is executed after 
encountering or receiving an END-MSG, then the message is terminated. If the desti- 
nation address is for another server then the message is passed to the conmiunication 
sub-system, compressed or encrypted, given a digital signature and then sent through a 
point-to-point connection to the receiving server. 
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List of acronyms 



ANSI 




American National Standard Institute 


CORBA 




Common Object Request Broker Architecture 


CSV 




Conmia Separated Value 


EDI 


— 


Electronic Data Interchange 


GIF 


= 


Graphics Interchange Format 


HTML 




Hyper Text Markup Language 


HTTP 


= 


HyperText Transfer Protocol 


ILMC 


— 


InterLingua'T^ Message Client 


ILMDB 


— 


InterLingua™ Message Database 


ILMF 


— 


InterLingua'^'^ Message Format 


ILMP 


— 


InterLingua™ Message Protocol 


ILMS 


■ — 


InterLingua™ Message Server 


IS 




InterLingua™ Message Script 


JDBC 


— 


Java DataBase Connectivity 


JPEG 





Joint Photographers Expert Group 


MIME 




Muli-purpose Internet Mail Extensions 


ODBC 




Open DataBase Connectivity 


RDBMS 




Relational Database Management Systems 


SNMP 




Simple Network Management Protocol 


SQL 




Structured Query Language 


URL 




Universal Resource Locator 


VRML 




Virtual Reality Markup Language 
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Claims 



1. 



Method of point-to-point conununication between a sender (SRV(m)) and a 



receiver (SRV(m)) by means of messages with flexible message formats (ILMF) char- 
acterized in that any of said messages comprises: 

a header at least comprising message definition references (MSG ID, MSG 
CLASS, MSG VERSION, MSG CREATOR), a sender identifier (SENDER 
ID) and a destination address (DESTINATION ADDRESS); 
message content regarding: 

* number of fields (FIELD COUNT) and content of any field (FIELD(l), 

-..); 

* number of objects (OBJECT COUNT) and content of any object 
(OBJECT(l), ...); 

* number of field mappings (MAP COUNT) and content of any field map- 
ping (MAP(l), ...)> field mapping being usable by predetermined fields; 

* number of actions (ACTION COUNT) and content of any actions 
(ACTION(l), ...), any action being at least usable by predetermined fields. 

2. Method according to claim 1, wherein said message definition references com- 
prise a message identifier (MSG ID) for identifying any of the messages. 

3. Method according to claim 1 or 2, wherein said message definition references 
comprise a message class identifier (MSG CLASS) for identifying a message class for 
any of the messages, like mail, business message, orders or shipping. 

4. Method according to any of the preceding claims, wherein said message defini- 
tion references comprise a message version identifier (MSG VERSION) for identifying 
a version number of any of the messages. 



5. Method according to any of the preceding claims, wherein said message defini- 
tion references comprise a message creator identifier (MSG CREATOR) for identifying 
a creator of any of the messages. 



wo 99/20025 



PCT/NL98/00586 



34 

6. Method according to any of the preceding claims, wherein said header com- 
prises a reference to a type of encryption (ENCRYPTION TYPE) applied. 

7. Method according to any of the preceding claims, wherein said header com- 
prises a reference to a type of compression (COMPRESSION TYPE) applied. 

8. Method according to any of the preceding claims, wherein said header com- 
prises a reference to an application (APPLICATION NAME) for indicating whether or 
not any of the messages is member of a series of messages forming together said 
application. 

9. Method according to any of the preceding claims, wherein any of said mes- 
sages comprises a digital signature. 

10. A communication apparatus comprising processing means (ILMS) and a data- 
base (ILMDB), arranged for point-to-point communication with another communica- 
tion apparatus (SRV(m)) by means of messages with flexible message formats (ILMF), 
said messages comprising: 

a header at least comprising message definition references (MSG ID, MSG 
CLASS, MSG VERSION, MSG CREATOR), a sender identifier (SENDER 
ID) and a destination address (DESTINATION ADDRESS); 
message content regarding: 

* number of fields (FIELD COUNT) and content of any field (FIELD(l), 

...); 

* number of objects (OBJECT COUNT) and content of any object 
(OBJECT(l), ...); 

* number of field mappings (MAP COUNT) and content of any field map- 
ping (MAP(l), ...), any field mapping being usable by predetermined fields; 

* number of actions (ACTION COUNT) and content of any actions 
(ACTION(l), ...), any action being at least usable by predetermined fields; 

said processing means (ILMS) being arranged for consulting a predetermined message 
definition table (msgdef) stored in said database (ILMDB) using said message defini- 
tion references as references to said predetermined message definition table. 



wo 99/20025 




PCT/NL98/00586 



35 



11. A communication apparatus according to claim 10, wherein said predetermined 
message definition table (msgdef) comprises a message identifier (msgid) for identify- 
ing any of the messages. 

12. A communication apparatus according to claim 10 or 11, wherein said prede- 
termined message definition table (msgdef) comprises a message class identifier 
(msgclass) for identifying a message class for any of the messages, like mail, business 
message, orders or shipping. 

13. A communication apparatus according to any of the claims 10 through 12, 
wherein said predetermined message definition table (msgdef) comprises a message 
version identifier (msgver) for identifying a version number of any of the messages. 

14. A communication apparatus according to any of the claims 10 through 13, 
wherein said predetermined message definition table (msgdef) comprises a message 
creator identifier (creatid) for identifying a creator of any of the messages. 

15. A communication apparatus according to any of the claims 10 through 14, 
wherein said predetermined message definition table (msgdef) comprises a reference to 
a type of encryption (encrtype) applied. 

16. A communication apparatus according to any of the claims 10 through 15, 
wherein said predetermined message definition table (msgdef) comprises a reference to 
a digital signature type (sigtype) applied. 

17. A communication apparatus according to any of the claims 10 through 16, 
wherein said predetermined message definition table (msgdef) comprises a message 
system identifier (msysid) for use as a reference to further tables in said database 
(ILMDB). 



18. A communication apparatus according to claim 17, wherein said further tables 
comprise a field definition table (flddef) for holding primary definitions for any field 
of said messages. 
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19. A communication apparatus according to any of the claims 17 or 18, wherein 
said further tables comprise a field mapping table (fldmap) comprising mapping infor- 
mation usable by predetermined fields, e.g. for mappings to hyper text markup lan- 
guage fields, database fields, flat file fields and other message fields, said database 
fields and flat file fields being stored in a customer database (CDB). 

20. A communication apparatus according to any of the claims 17 through 19, 
wherein said further tables comprise a field action table (fldact) comprising action 
information usable by predetermined fields. 

21. A communication apparatus according to any of the claims 17 through 20, 
wherein said further tables comprise a message pre-processing table (msgpre) com- 
prising a list of actions to be executed as pre-processing for a message either received 
or to be sent and a message post-processing table (msgpost) comprising a list of 
actions to be executed as post-processing for a message received. 

22. A communication apparatus according to any of the claims 20 or 21, wherein 
said field action table (fldact), said message pre-processing table (msgpre) and said 
message post-processing table (msgpost) comprise references to types of action 
selected from the following group of actions: database type of actions and logical type 
of actions including mathematical calculations, assignments, logical operations, condi- 
tional operations, and commands. 

23. A communication apparatus according to any of the claims 10 through 22, 
wherein said message definition table (msgdef) comprises an application field 
(appmain) for indicating whether a message received is a first message of an applica- 
tion and an application name field (appname) for referring to a name of said appli- 
cation. 

24. A communication apparatus according to claim 23, wherein said application is 
a distributed application distributed over a plurality of communication apparatuses. 



25. A communication apparatus according to any of the claims 10 through 24, 
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wherein said apparatus is arranged for requesting a new message definition from a 
sender if a message received refers to a message definition not present in its database 
(ILMDB), and receiving said new message definition from said sender and storing it in 
said message definition table (msgdef) in said database (ILMDB). 

26. A communication apparatus according to any of the claims 10 through 25, 
wherin said processing means (ILMS) are arranged to either merge a message received 
with a designated HTML file or if the designated HTML file is not found by the pro- 
cessing means (ILMS), to create a default dynamic HTML file. 

27. A system comprising a communication apparatus (SRV(m)) according to any 
of the claims 10 through 25 and a terminal (ILMC) connected to said communication 
apparatus, said terminal comprising a terminal processor (1), a display unit (6) and 
input means (12, 13) for inputting data by a user, said communication apparatus being 
arranged for passing a message received to said terminal if said terminal is indicated in 
the message to be the destination address, and said terminal processor (1) is arranged 
to either merge the message with a designated HTML file or if the designated HTML 
file is not found by the terminal processor (1), to create a default dynamic HTML. 
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the report since they do not contain amendments,): 



Description, pages: 

2,3,5-9,14-28, 
30-32 

4,11-13,29 

1,10 



as originally filed 

as received on 
as received on 



29/1 0/1 999 with letter of 
07/12/1999 with letter of 



29/10/1999 
07/12/1999 



Claims, No.; 

1-28 



as received on 



07/12/1999 with letter of 



07/12/1999 



Drawings, sheets: 

1/3-3/3 as originally filed 

2. The amendments have resulted in the cancellation of: 

□ the description, pages: 

□ the claims, Nos.: 

□ the drawings, sheets: 

3. □ This report has been established as if (some of) the amendments had not been made, since they have been 

considered to go beyond the disclosure as filed (Rule 70.2(c)): 



4. Additional observations, if necessary: 
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V. Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial 
applicability; citations and explanations supporting such statement 

1. Statement 

Novelty (N) Yes: Claims 1-28 

No: Claims 

Inventive step (IS) Yes: Claims 1-28 

No: Claims 

Industrial applicability (lA) Yes: Claims 1 -28 

No: Claims 



2. Citations and explanations 
see separate sheet 
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Re Item V 

Reasoned statement under Article 35 (2) with regard to novelty, inventive step or 
industrial applicability; citations and explanations supporting such statement 

The invention is In the field of point-to-point communication between different data- 
bases by exchanging messages according to independent method claim 1 and 
independent apparatus claim 10, and system claim 27 making reference to the 
apparatus claims. 

Closest prior art to this application is document D1 (EP-A-0 456 249) disclosing a 
communication method in which messages are transformed into a common format (the 
intermediate data representation) before being transmitted to another database system. 
The common message format has inherent restrictions. 

The invention is based on the problem to provide a communication method and 
apparatus for exchanging messages between different database systems wherein the 
messages may include whole application level programs. 

The invention overcomes this problem with a method and an apparatus for exchanging 
messages having a structured format including data fields and object fields. The 
method and apparatus further include databases at the respective end points of the 
communicating systems which allow the local interpretation and processing of incoming 
messages. 

The prior art does not provide a hint in this regard. Therefore, the subject-matter of 
claims 1 and 10 is considered to be novel (Article 33 (2) PCT) and to involve an 
inventive step (Article 33 (3) PCT). Consequently, the subject-matter of the dependent 
claims 2 to 9 and 11 to 28 concerning embodiments of the method and the apparatus, 
respectively, is also considered to be novel and to involve an inventive step. 

There is no doubt about the industrial applicability (Article 33 (4) PCT) of the subject- 
matter of all claims. 
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Method of object oriented point-to-point con..unication and con^muni^iion apparatus 
for carrying out such a method. 

Field of the Tnvpntir^n 

The present invention relates to a method, an apparatus, and a system as defined 
m the preantble of claims .. ,0, and 28, respectively. These claims have been delimited 
from nP-A-O 456 249. The invention is in the area of electronic data communications 
dato^se organized, flexible fom,a. electronic data message management. cUent-server 
and distributed software applications. 

In particular, the invention uses a relational database to describe and manage the 
creation, communication, interpretation, display and real-time responses to flexible 
ormat electronic data messages and applications organized as collections of flexible 
fonnat electronic data messages which may be optionally distributed across one or 
more computer systems on one or more electronic data networks. 

Backurnund of ih^ lnv^nij»„ 

General purpose and business specific electronic data communication meets with 
four d.s„nc. problems, each of which has many sub-problems. We will be discussing 
these .ssues with regard to business communication needs, although the following 
potnts can apply to almost any category of electronic data communications. The four 
problems are: 

1) The electronic data that is sem and received must be clearly recognized for 
what .. ,s mean, to be. Each company has a different way of representing even the most 
bas,c business information, an order form or bill of lading, for example 

2) One electronic data is received from another company and correctly 
recognized, it must be integrated into the receiving company's database and business 
processing programs. Here again, each company has many differences in their database 
structures, which means the way they represent and store their electronica data on their 
computer systems. 

3) If the elecu-onic data must be displayed to an end user and allow for end user 
interaction, here again each company may be using different types of computer display 
terminals with various types of display software, various system .equirements and 
business requirements. It is very often necessary to build very expensive electronic 
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specific data items to specific locations in a customer database or storage device. This 
mapping is not created in software, but is in some more easily changeable and flexible 
representation that is separate fi-om the software application and customer database, 
such as an independent flat file that the software application reads. This eliminates the 
need to reprogram and rebuild the software application every time the database struc- 
ture or the data representation changes. Data field mapping techniques are in common 
use by many database companies such as Progress, Oracle and SQLBase (SQL = 
Structured Query Language). A version of this well knowjmethod rfi^J^^part of the 
functionality and methodology incorporated into communication apparatus of the pres- 
ent invention. 

Problem 3 

The third problem has had few easily workable general purpose solutions. One 
category of solutions requires writing extensive amounts of software code for various 
window (graphical user interface) management systems such as X-Windows or Micro- 
soft Windows. For large, multi-functional business applications, this approach requires 
a tremendous amount of time, money and effort, and makes changes or additions to the 
user interface a very time consuming and costly affair as well. 

A new and promising category of solutions centers around the use of HTML 
(H>per Text Markup Language) and web browsers, which can dynamically create very 
nice looking graphical user interfaces, usually called 'web pages', because they are 
used on the World Wide Web and the internet. This has aroused the interest of many 
companies. They see how quickly and cheaply very nice looking graphical user inter- 
faces can be built using HTML and they wonder if the user interfaces for their elec- 
tronic data communication and processing programs could be created in the same way 
and communicate over the same networks as the web browser systems. In fact, com- 
panies would like to be able to use the internet to send and receive the full range of 
business and personal data and messages. 

At the present time there are several systems available thai will allow a limited 
range of business and general data communication over the internet, using HTML and 
web browsers. The reason that the types of data communication are limited is that the 
webserver/web browser systems were not designed to provide full data communication 
services. They were designed as dynamic document retrieval and display systems. They 
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Given the above, an urgent need arises for a single system and a way of 
communicating that can solve each of these four issues and combine the solutions into 
one unified whole. This would be of great benefit to the individuals and companies that 
must build complex electronic data communication systems and who must face these 
issues oh a daily basis. Such a system and communication method would reduce the 
time, cost and complexity of building and maintaining electronic data communication 
systems drastically. 

To obtain the object referred to above, the present invention claims a method of 
point-to-point communication between a sender and a receiver as defined at the outset 
and as characterized by the characterizing features of claim 1 . 

Consequently, all of the elements for defining application level fimctionality are 
present in the message format, which is already in the context of a network 
communication system and therefore may be easily distributed by simply changing a 
location and destination address. 

Moreover, in accordance with the present invention, a communication apparatus 
is claimed in accordance with independent claim 1 0. 
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11 ^cx*^«^^^^ 
numb e r of field mappings and cont e nt of any field mapping^ an^ 



mapping being usable by predetemiinedjis 
* number of a\ {\\\\\{\ iiiiil i mih nl of any actions, any action being at least 
usable by predetermined fields; 



table stored in the database ininr tlir. mrnnnj^r ili llliil Ii , as references to the 

^ muiod mocoago dofiwition 



Thus, in the present invention a flexible message format is defined that can 
contain any type of data and that contains enough information to fully describe the 

10 data within the message itself Any message comprises message definition references 
^ which are used by the claimed communication apparatus receiving the message to 

identify a message definition preloaded in its database. However, the technology is 
flexible since the preloaded message definition is not fixed for once and for all. Within 
the communication apparatus receiving the message, message format specific instances 

15 can be created, edited or deleted by inserting, updating or deleting entries in relational 
database tables which fully describe the message and reference it with a unique ident- 
ifier. Moreover, if message definitions are absent at a desired location, entire database 
message definitions may be exchanged automatically for particular messages or groups 
of messages, thereby creating easily exchanged common format messages for multiple 

20 users. A further advantage of the present invention is the small amount of necessary 
overhead. 

1^ Examples of fields within the message definition references are a message 

identifier for identifying any of the messages, a message class identifier for identifying 
a message class for any of the messages, like mail, business message, orders or ship- 
25 ping, a message version identifier for identifying a version number of any of the mess- 
ages, and a message creator identifier for identifying a creator of any of the messages. 
Any of these fields within the message definition references have equivalent counter- 
parts within the message definition table in the claimed communication apparatus. 

Moreover, headers of messages may include a reference to a type of encryption 
30 and/or compression used. Also these references, then, have counterparts in the message 
definition table in the communication apparatus. 

Preferably, the content of messages is protected by digital signatures. 
Preferably, the database of the communication apparatus is organized in several 
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tables to which reference is made from the message definition table. Then, the prede- 
termined message definition table comprises a message system identifier for use as a 
reference to further tables in the database. 

One of such further tables may be a field definition table for holding primary 
definitions for any field of the messages. 

Preferably, one of such further tables is a field mapping table comprising map- 
ping information usable by predetermined fields, e.g. for mappings to hyper text mark- 
up language fields, database fields, flat file fields and other message fields, said data- 
base fields and flat file fields being stored in a customer database. Then, the message 
format according to the invention contains not only data, but also mapping commands 
for user interfaces, customer database fields, and sequences of actions including calcu- 
lations and conditional logic. Consequently, all of the elements for defining application 
level functionality are present in the message format, which is already in the context of 
a network communication system and therefore may be easily distributed by simply 
changing a location and destination address. Moreover, in this way the HTML standard 
may be incorporated for generating very easily built, fast and flexible graphical user 
interfaces, allowing a direct mapping to and from the message format defined by the 
invention, as managed, defined and controlled by the claimed communication apparatus 
and displayed and interacted with on a user terminal, like a microprocessor, connected 
to the communication apparatus. 

^^^^^AdditipnaHy, one of such further tables may be a field action table comprising 
ction i ffo^ati oirusable by predetermined fields. 

Preferably, further tables are a message pre-processing table comprising a list 
of actions to be executed as pre-processing for a message either received or to be sent 
and a message post-processing table comprising a list of actions to be executed as 
post-processing for a message received. 

The field action table, the message pre-processing table and the message post- 
processing table comprise references to types of action selected from the following 
group of actions: database type of actions and logical type of actions including math- 
ematical calculations, assignments, logical operations, conditional operations, and com- 
mands. 

Preferably, in the present invention, applications are defined as a named group 
of one or more messages. To that end, the message definition table comprises an appli- 
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cation field for indicating whether a message received is a first message of an applica- 
tion and an application name field for referring to a name of the application. 

In accordance with the present invention, the claimed communication apparatus 
is, preferably, arranged for requesting a new message definition from a sender if a 
message received refers to a message definition not present in its database, and receiv- 
ing said new message definition from said sender and storing it in said message defini- 
tion table in said database. 

The processing means of the communication apparatus may be arranged to 
either merge a message received with a designated HTML file or if the designated 
HTML file is not found by the processing means, to create a default dynamic HTML 
fil^- However, alternatively, the processing means of the communication apparatus may 
instruct a connected terminal to carry out these functions. Therefore, the present inven- 
tion also relates to a system comprising a communication apparatus as defined above 
and a terminal connected to the communication apparatus, the terminal comprising a 
15 terminal processor, a display unit and input means for inputting data by a user, the 
communication apparatus being arranged for passing a message received to the ter- 
minal if the terminal is indicated in the message to be the destination address, and the 
terminal processor is arranged to either merge the message with a designated HTML 
file or if the designated HTML file is not found by the terminal processor, to create a 
20 default dynamic HTML. 

Thus, user terminals that receive a message for which the terminal processor 
does not have the corresponding message definition can rely upon the system's auto- 
matic interpretation and display which is based upon the self-describing information 
contained within the message received. This same self-describing information can then 
25 be used by the terminal processor to automatically create a default database message 
definition if the database message definition referred to by the message can^ found. 
Such a default database message definition can then be edited and adapted to the local 
system by the terminal user. 

The present invention may include a state of the art solution for problems two 
30 and three combined in a unique way with completely new solutions to problems one 
and four, all built around a unique flexible format electronic data message management 
system composed of the claimed flexible message format and communication appar- 
atus. 
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checksums for monitoring message integrity with the use of digital signatures. This 
allows for complete confirmation of the non-corrupted state of the received message 
and, at the same time, the security verification of the identity and authenticity of the 
sender. The communication sub-system exists in both the server SRV and the terminal 
ILMC. The communication sub-system is designed to be network protocol indepen- 
dent. In its current version it will run on TCP/IP, XTP/IP and XTP/ATM/AAL5, but it 
will just as easily run on AppleTalk, IPX, SNA, X.25, DECNET, OSI or any other 
protocol that can use a socket interface and point-to-point addressing scheme. 

The communication sub-system is not a critical part of the present invention. 
The advances of the present invention may be implemented over many different types 
of communication sub-systems. Those skilled in the art will recognize that the type and 
implementation details of the chosen network communications sub-system will not 
change the functionality of the present invention, as long as the communication sub- 
system has a reliable delivery protocol that can guarantee a high rate of delivery suc- 
cess and data integrity. 

A message priority scheduling and service mechanism as described and 
claimed in European Patent Application 97202945.8/^5/ be added to the communica- 
tion sub-system. This mechanism uses separate connections for individual priority 
levels and a simple network and system buffering algorithm to automatically guarantee 
fair service for all message priority levels. This mechanism delivers high priority mess- 
ages faster consistently, without the need for a complex scheduling algorithm to moni- 
tor message sizes or prevent lower priority message lock-out. 

Receiving A Messaee 

When a message is received by a server SRV(m), it will pass through the 
communication sub-system. The digital signature will be verified and the transport 
layer header will be stripped. If the message has been encrypted or compressed it will 
be decrypted or decompressed at this time. The message will then be passed to the 
database layer ILMDB. 

If message definitions are absent at a desired location, entire database message 
definitions may be exchanged automatically for particular messages or groups of mess- 
ages, thereby creating easily exchanged common format messages for multiple users. 

Alternatively, if a message definition does not exist for the message received it 



